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Description 
System and Apparatus for Bidding 

[ 1 ] Cross-reference to related applications 

[2] This application is a non-provisional of US application number 60/535,437 filed 

January 8, 2004, which application is incorporated herein by reference for all purposes. 
[3] Background 

[4] Auctions have been around for nfiillennia. 

[5] Until very recent times, all auctions have been conducted in vivo; bidders or their 

agents are required to be physically in the same room for the auction to take place. 
Each would-be bidder is either in the room (or is in communication with an agent in 
the room) or is not in the room (and has no agent in the room). If the bidder (or the 
bidder's agent) is in the room, then the bidder is instantly and continuously aware of 
the fact that the auction is taking place. It is unlikely^ or perhaps impossible, for the • 
bidder who is in the room to be unaware that an auction of a particular item is taking . 
place. On the other hand, if the bidder is not in the room (and has no agent in the 
room) then the bidder is by definition unaware of what is being auctioned. 

[6] Books, movies, and television have all portrayed such auctions, from raucous slave 

auctions in ancient Rome to polite art auctions at Christie's and Sotheby's where well- 
dressed bidders indicate bids by raising numbered paddles, with some bids com- 
municated by telephone to and from bidders who are geographically distant from the 
auction house. Retellers of urban legends like to describe livestock auctions where bids 
are indicated by subtle gestures and nods, and where a newcomer might, by scratching 
an itch, unknowingly purchase a cow or horse, then (so goes the urban legend) by 
some other unwitting action, resell the cow or horse at a profit. 

[7] Books, movies, and television have likewise portrayed stock and commodities 

exchanges having a "trading pit" where brokers shout out orders and where slips of 
paper serve to memorialize matches between buyer and seller. Historically the physical 
limitation on the size of the trading pit puts a natural upper bound on the number of 
participants that can fit in the room, and this has led to a limit of the number of "seats" 
at the exchange. A would-be buyer or seller is forced to go through a broker rather 
than to participate directly in the trading activity. 

[8] Technology has slowly crept into auctions and into exchanges, many of which are 

carried out in silica rather than in vivo. Some stock exchanges are now largely 
electronic, and some of them do not even have a 'trading pit." Perhaps best known of 
the electronic auction systems is eBay. With eBay, there is no requirement that the 
bidders all be in the same geographic location. Advances in computer networking and 
teleconomunications (chief among them the rise and penetration of the Intemet into 
society and conmierce) have reduced the need to trade or bid through an agent or 
broker, and have vastly increased the number of participants capable of participating. 
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Few would consider it an overstatement to say that the world of auctions has been 
transformed in kind;, and not merely in degree, by the advent of eBay and other 
automated auction systems. 

[9] But experience with contemporary automated auction systems soon leads to a re- 

alization that it is not easily within grasp for a would-be bidder to be confident of 
bidding optimally in a given auction system. A few examples will suffice to illustrate 
this problem, and those experienced in the art will have no difficulty recounting ex- 
periences of their own to highlight this problem. 

[10] As one example, there is the problem of simply learning that a desired item is 

available for auction. 

[11] In a classic Christie's or Sotheby's auction, the would-be bidder is either present in 

the auction room (directly or through a proxy) or is not. If the would-be bidder is not 
present, then the would-be bidder will stand no chance of winning bids, but this simply 
follows automatically from the fact of not being present at the auction. To the extent 
there is some missed opportunity to bid, the would be bidder who has failed to attend 
will not feel that the system has filed him or her, as the problem could have been 
readily cured simply by showing up for the auction. On the other hand, if the would-be 
bidder is present in the room, then it is easy enough to keep track of every single item 
being auctioned, as the auctions take place seriatim, 

[12] But in a contemporary online auction, there can be a million or more items all 

being auctioned simultaneously. Quite simply it is not humanly possible to follow all 
items being auctioned and to be confident of bidding optimally as to all items for 
which one would desire to bid. 

[13] In this world of online auctions, the would-be bidder will select among the millions 

of pending auctions and will bid on only a few of the items. For a system such as eBay, 
the selection process tends to follow two main paths. 

[14] First, a would-be bidder can ''drill down" through a classification system. For 

example a would-be bidder may start in ''Computers & Networking" and then narrow 
the search to "Networking," then to "Wireless Networking,", then to "WiFi," then to 
"PC Cards,", then to "USB, Adapters, NICs,", and finally to "PC Cards, PCMCIA 
(Laptop),", in a numerical classification (in the case of eBay) of 4S000. Having done 
this, the would-be bidder can return again and again to the numerical class and can 
review the pending items for auction which are in this class, perhaps bidding for one or 
more such items. 

[15] Second, a would-be bidder can search, looking for particular words or phrases in 

the titles or titles and descriptions of pending auctions. This may yield a list of items 
matching the search terms, and the would-be bidder can review the pending items, 
perhaps bidding for one or more such items. 

[16] Experienced would-be bidders can vary their approaches, for example using a mix 

of search terms and numerical classes to narrow down the field of items upon which 
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bids may be made. A variety of other search approaches may be used as well. 
[17] It will be appreciated, however, that these and most other searching approaches 

rely in a fundamental way on behavior and decisions of persons whom one does not 
know and has not met. Such sellers may make classification decisions that are, from 
the point of view of the would-be bidder, irrational or inscrutable. Likewise such 
sellers may choose vocabulary in titles or descriptions that differs from the vocabulary 
that the would-be bidder would have expected to see used. The allocation of key words 
(by the seller) between the "title" and "description" fields may also turn out to be 
different from what the would-be bidder would have expected. Stated in a somewhat 
colorful and figurative way, the would-be bidder who is going to depend (for a 
successful search) upon classification and description decisions by unknown sellers is 
relying upon the kindness of strangers. Experience shows that such reliance is not 
always well placed. 

[18] Yet another aspect of the problem is that it will sometimes turn out that a seller 

may not even appreciate what there is about an item that would be of interest to a 
bidder. For example an antique photograph noiay show a particular item in the comer, 
• and the bidder may be interested in the photograph because of the item in the comer. 
Searching on a textual description of the item may not reveal this reason for interest, 
and looking at classifications (categories) may likewise not reveal it. It would be very 
. helpful if methods and apparatus could be devised which would help to find such ' 
' ' items. 

[19] - Among those would-be bidders who take seriously a goal of being thorough and 
bidding optimally, however, many experiences make it easy to leam of missed op-- 
portunities. A would-be bidder can search "closed items," that is, items for which the 
' . « bidding has ended and for which a winning bidder has been identified. Such a search is 
generally carried out just as described above, for example, through numerical classes 
or word searches or a combination of both, and identifies items which the^ would-be 
bidder missed. 

[20] Yet other missed opportunities may arise for which the would-be bidder never even 

learns that there was a ndssed opportunity. The same key word or classification search 
that failed to identify an item during the time it was being auctioned will, likely 
enough, fail to identify it later when one searches closed items. 

[21] It should be appreciated that classic in-person auctions never really present these 

problems. If the bidder was in the room, the bidder could not help but leam of each 
item as it came up to be auctioned. If the bidder chose not to attend the auction, then it 
was that decision (and not any feared inattention or failure to search well enough) that 
led to the failure to win the bidding. 

[22] Those skilled in the art will readily appreciate that real money is at stake. The 

would-be bidder who fails to leam that some item could have been purchased for, say, 
$80,000 and who instead is forced to bid $100,000 for some other comparable item has 
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spent an extra $20,000 unnecessarily. Likewise the enjoyment to be derived from an 
item once purchased can have immeasurable value; the would-be bidder who fails to 
learn that some item can be purchased presently, and who is instead forced to wait 
some weeks until a comparable item comes up for bid, has needlessly foi;gone such 
enjoyment for those weeks. Finally if an item is unique, later items may be of no 
consolation. 

[23] Patents and publications mentioning auctions and exchanges include US 

2004/0267731 entitled "Method and system to facilitate building and using a search 
database," US 2004/0193525 entitled "Online biddmg system and method of the 
same," US 2002/0082977 entitled "Aggregation of on-line auction listing and market 
data for use to increase likely revenues from auction listings," US 6732161 entitled 
"Information presentation and management in an online trading environment," US 
6058417 entitled "Information presentation and management in an online trading en- 
vironment," US 6044363 entitled "Automatic auction method," US 6012045 entitled 
"Computer-based electronic bid, auction and sale system, and a system to teach new/ 
non-registered customers how bidding, auction purchasing works," US 2002/0023037 
entitled "Exchange method and apparatus," and intemational patent publication WO 
00/62225 entitled "Marketplace system fees enhancing market share and par- 
ticipation." 

[24] Despite these great needs, and despite many attempts to address these needs, there 

has until the present time been no truly new approach to these needs. Approaches 
proposed until now have been merely incremental in their advance (e.g. applying a • 
thesaurus to the search terms) and it would be helpful if wholly new approaches could 
be foimd. 

[25] Summary of the Invention 

[26] In connection with a computer-based auction system, the auction system commu- 

nicatively coupled with sellers and bidders, the system having records indicative of 
sellers of items and records indicative of bidders for the items and identifying for each 
item a winning bidder in an auction, a first bidder selects a first item. By electronic 
means, information is obtained indicative of identities of second bidders other than the 
first bidder who previously placed respective bids for the first item. Second items are 
found other than the first item for which bids have been placed by one or more of the 
second bidders. A second item is chosen by the first bidder, for which the first bidder 
was not aware of the second item until after this work is done. The first bidder may 
then attempt to discern why the first bidder was not aware of the second item until 
after the auction ended. Alternatively this approach is used to identifying a second item 
for which the auction has not yet ended, and the first bidder places a bid higher than 
any bids previously placed for that second item. 

[27] Description of tlie drawing 

[28] The invention will be described with respect to a drawing in several figures. 
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[29] Fig. 1 shows in functional block diagram fonn a typical online auction system, 

together with apparatus 22 according to the invention. 
[30] Fig. 2 shows apparatus 22 of Fig. 1 in greater detail, in functional block diagram 

form. 

[3 1] Fig. 3 shows in flowchart form a first method according to the invention. 

[32] Fig. 4 shows in flowchart form a second method according to the invention. 

[33] Fig. 5 depicts relationships among various data records in the system according to 

the invention. 

[34] Fig. 6 shows a user interface flowchart for apparatus according to the invention. 

[35] Detailed description 

[36] Fig. 1 shows in functional block diagram form a typical online auction system 13, 

together with apparatus 22 according to the invention. Online auction system 13 may 
be seen, which is communicatively coupled (e.g. by the Internet through web-based 
interfaces) with sellers 19 and bidders 20 through links 23 and 24 respectively. In an 
examplary embodiment (e.g. eBay) there is a database 15 of sellers, a database 14 of 
bidders, a database 10 of items being auctioned, and a database 1 1 of bids placed for 
the items being auctioned. As indicated by arrow 17, a seller listed in database. 1 5 may 
list an item for auction by causing the item to be listed in database 10. Bidders listed in . • 
database 14 place bids, indicated by arrow 18, which are accumulated in bid database 
11.. 

[37] It will be appreciated that the precise database structure of the online auction 

system 13 can vary and the particular design choices made do not affect the invention 
itself or its benefits. Stated differently, the invention offers many or all of its- benefits 
regardless of the particular design choices made in system 13. For example, it may • 
prove convenient to use a single database 16 to contain member identifiers, with each 
member able to serve as a bidder or seller or both depending on the particular item = 
involved. Likewise databases 10 and 1 1 may be stored as a single database 12 within 
the system 13, although this is thought to be less preferable. 

[38] Sellers and bidders are, in a typical system 13, identified by unique identifiiers 

called user IDs which serve as pointers into database 16. Items being auctioned are, in 
a typical system, identified by unique item numbers which serve as pointers into 
database 10 and optionally into database 11. 

[39] It will also be appreciated that the particular physical storage and computational 

facilities used in system 13 may be arranged in any of several ways as a matter of 
design decision by the designer of the system 13, In a very simple case a single 
computer and disk storage system can perform all the functions just discussed. In a 
large system with millions of users and millions of listed items, it is preferable to break 
up the many functions into separate physical parts. For example one server may serve 
as "firont end" for web-interface visitors, while a second server may be devoted to servi 
ng up images and other items of data that change only slowly (e.g. item descriptions). 
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Yet another server may collect bids while a fourth server may authenticate visitors 
who are logging into the system. Those skilled in the art will appreciate that as the 
system scales, other approaches may be taken to support bandwidth needs. Ten bid- 
related servers may divide up the task of receiving bids and keeping track of who is the 
highest bidder, each based upon the final digit of the item number, for example. 
[40] Those skilled in the relevant art will likewise be aware of standard approaches to 

system reliability, such as mirrored and striped RAID which improve fault tolerance 
and which reduce latency of disk accesses, all of which are omitted for clarity in Fig. 
1. 

[41] Importantly, a bidder 21 who enjoys the benefits of the invention is communicately 

coupled with the system 13 by means of link 25. The bidder 21 uses system 22 in an 
attempt to bid optimally, minimizing lost bidding opportunities. System 22 is, in an 
exemplary embodiment, a general-purpose personal computer running a suitable stored 
program, the computer located nearby to the user 21 and havmg a user interface 26 
such as a keyboard, pointing device, and screen, and the computer connected by means 
of the Internet to the system 13. In this embodiment, which might be termed a "thick 
client" embodiment, there are typically as many personal computers (each providing 
system 22) as there are users 21. 

[42] In a second exemplary embodiment which might be termed an ASP (application 

service provider) or "thin cUent" embodiment, the system 22 is a server and the user 
interface 26 is a web-based interface. System 22 in this embodiment actually serves 
many users 21, each user having a respective user interface 26. It will be appreciated 
that there are advantages and disadvantages to these two approaches to providing the 
benefits of the invention to users 2 1 , and it will also be appreciated that the invention 
can provide its benefits in embodiments differing firom these t>yo approaches, none of ' 
which depart in any way fi'om the invention. ' 

[43] Fig. 2 shows apparatus 22 of Fig. 1 in greater detail, in functional block diagram 

form. User interface 26 is coupled with apparatus 22. Included in apparatus 22 is a 
database 29 of items of interest to the bidder 21, a database 28 of competing bidders, 
and a database 27 of search keys used for searching. The search keys fi'om the database 
27 are, as described below, used among other things to perform searches upon 
database 10 of items being auctioned. The database 28 of competmg bidders will, in an 
exemplary embodiment, consist in large part of user IDs of such competing bidders, 
and are used to perfonn queries in system 13 to learn what items (if any) those 
competing bidders have bid on. Finally the database 29 of items of interest will, in an 
exemplary embodiment, consist in large part of item numbers, and are used to perform 
queries in system 13 to learn the status of items being auctioned. 

[44] Fig. 3 shows in flowchart form a first method 45 according to the invention. By 

way of review this method 45 is carried out with respect to computer-based auction 
system 13, the auction system communicatively coupled 23, 24 with sellers 19 and 
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bidders 20, the system 13 having records (in database 15) indicative of sellers of items 
and records (in database 14) indicative of bidders for the items and identifying for each 
item a winning bidder in an auction. At 40 a first bidder 21 selects a first item for 
which there is a winning bidder. In a simple case it is an item for which the winning 
bidder is not the same as the first bidder. (Alternatively this may be a case where the 
item is one where the first bidder was indeed the winning bidder, or may be a case 
where the item is simply one where the first bidder has placed a bid.) 
[45] Stated differently, in this simple case the user of the invention learns that he or she 

has lost an auction. The apparatus 22 then, in an automated way at box 41, obtains 
from system 13 information indicative of identities of second bidders other than the 
first bidder who previously placed respective bids for the furst item. The identities of 
the second bidders are placed for example in database 28. The apparatus 22 then, in an 
automated way at box 42, finds second items other than the first item for which bids 
. have been placed by one or more of the second bidders. The first bidder can then 
choose (at box 43) from among those second items, perhaps identifying an item that 
tiie first bidder had not previously found through previous searches of the kinds 
employed in the prior art. In a typical case the furst bidder will not even learn of the 
existence of this item until after its auction has ended at which time it is too late to bid 
on it. It is not, however, too late to attempt to leara something from what happened. 
Thus the first bidder, can then (at box 44) attempt to discern why the first bidder was 
not aware of the second item until after the auction ended. This may include studying 
to see how this second item was classified by its seller; this may educate the user as to 
classifications that this seller, or other sellers, might choose to use in future for such 

items. This may also include stud3ang to see the vocabulary that was selected by this 
seller, which may educate the user as to the vocabulary which this seller, or other • 
sellers, might use in future. It may also be fruitful to take note of the seller's allocation 
of words as between the title and the description. If the user had previously searched 
for certain key words only in the title, and if such key words were seen (through this 
study) to turn up often in the description and not in the title (as one example) then the 
user could take this into account for future searches. 

[46] Consider, too, the case where a user did not fully appreciate ways in which sellers 

might misspell certain words in an item description. This study, in which a competing 
bidder somehow found the item despite the misspellings, might well assist the user in 
appreciating the possible benefit of searching usmg just such misspellings in future. 

[47] The learning opportunities provided in this way can benefit the user in at least two 

different ways. The user may, through more informed searching in future, come to 
leam of items that can be had at lower prices than items that would have been found 
through less effective searches. Or the user may leam of an item sooner, win it sooner, 
aad enjoy its benefits sooner. Finally, for some unique items, such as coUectables, 
there may be only one chance to obtain a given item and if the item is lost that may be 
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the end of the matter. 

[48] Fig. 4 shows in flowchart form a second method 50 according to the invention. In 

this method, the user selects (at box 51) a furst item of interest. This may for example 
be an item for which someone else was the winning bidder. Alternatively this may be 
an item that has an auction in progress, an item of interest to the user. The system 22 
then (at box 52) obtains information indicative of identities of second bidders other 
than the first bidder who have akeady placed respective bids for the first item. The 
system 22 then (at box 53) finds second items other than the first item for which bids 
have been placed by one or more of the second bidders. The first bidder (at box 54) 
may then choose a second item for which the auction has not yet ended and for which 
the first bidder has not yet placed a bid. At box 55, the first bidder (user) places a bid 
electronically for the second item prior to the end of the action, the bid higher than an> 
bid previously placed for the second item. Of course it is hoped that the user may in 
this way have the good fortune to win that auction. It will be appreciated that in this 
way the would-be bidder will have learned of some item available for bidding that the 
would-be bidder might well not have learned about through conventional searching 
techniques. Experience also shows that these approaches can save the human user 
hours of searching time as compared with previous methods of searching. 
To take up again the '^photograph" example mentioned above, if a competing bidder 
has noticed the item of interest in the comer of the photograph, this approach may. 
pennit coming to leam of the item (and its reason for being interesting) in enough time 
to place a bid on the item. 

[49] Other benefits include the fact that this new information may save money for the 

bidder by permitting winning the present item for a lower price than some other 
comparable item for which the bids have risen (or will later rise) to a higher price. Al- 
ternatively this new infonnation may enable the bidder to learn of, and purchase, an 
item right away, when a comparable item might not otherwise have come to the 
attention of the bidder (through conventional searching) until some later time. Finally, 
as mentioned above, this new information may permit finding and acquiring unique 
items that would otherwise be lost and for which there is no ready substitute. 
One variant of the invention calls for "auto-adding" competing bidders. The user looks 
at items that other bidders are bidding on. The user looks at how frequently it has 
happened that some other bidder has bid on the same items that the user has bid on, 
and if some threshold is reached that other bidder will be added to a bidder list. Al- 
ternatively, such an other bidder can be manually added to the bidder list. 

[50] One way to think about the apparatus according to the invention is that it pemiits 

tracking and analyzmg the actions of other participants in an auction system in order to 
locate items which might otherwise not have been found. The apparatus analyzes the 
similarities between the user and the other participants in the auction system. 

[51] It will be appreciated that while the chief benefits of the invention are thought to 
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offer themselves in the context of an automated online auction system, these benefits 
may in some circmnstances also offer themselves in auctions held in person, by proxy, 
or by any other medium. 

[52] The apparatus can allow the user to designate which categories (classifications) he 

or she typically browses when searching for items in an auction. These categories are 
entered into the system, perhaps by selecting them from a web-based menu or by 
entering in numerical classification values. The system keeps a current cache of items 
listed in these categories. This cache is updated at predefined intervals or as requested 
by the user. A set of user-defined filters may be applied to the results of this searching. 

[S3] The apparatus can allow the user to define search tenns. The system fetches all 

matching items fi'om the auction system and saves them in a local database. Again, 
user-defined filters may be applied to the results of this searching. 

[54] The system can also allow tiie user to designate other auction participants that the 

user typically competes with in the bidding process. This is done by storing user IDs of 
those participants. The system then fetches all of the others items that these par- 
ticipants are bidding on. These items are stored in the aforementioned item cache. 

[55] The system can also allow the user to specify manually item numbers of items of 

interest. The system retrieves the status of such items firom the auction system and 
makes this infonnation available to the user. 

[56] The system can also look for all auctions which the user has bid on, and can 

retrieve the identifiers of all of the sellers for those items, as well as all of the 
competing bidders for those items. 

[57] As was mentioned above, the system desirably pennits the user to set up filters so 

that not all of the retrieved items are displayed. Typical filters can be on maximum 
. price, minimum price, geographic region, or items that have received fewer than some 
number of bids. A "filter-out" keyword can filter out items containing certain key ; 
words. 

[58] It is also desirable to be able to specify "highlight words" which are highlighted 

when an item is displayed. The highlighting can be by color, font, or other distinctive 
quality of text. 

[59] In an exemplary embodiment, the system will keep track of how often a particular 

bidder turns out to be a competing bidder. When this happens more than some pre- 
determined number of times (set by the user, or by default) then this bidder will be put 
into a list of "bidders to watch." The system then automatically tracks everything that 
such a bidder bids on, and reports it to the user. The same can be done for sellers who 
turn up repeatedly among sellers of items of interest. 

[60] Fig. 5 depicts relationships among various data records in the system according to 

the invention, all of which are discussed in detail below. Reading down the first 
column on the left, there is a search entity, and below it a category entity. Call tracking 
and error logging records are shown, discussed below. Reading down the middle 



wo 2006/075212 



10 



PCT/IB2005/050113 



coliunn, there are data records representing bidders. Below that is a data record rep- 
resenting a user of the system, and a data record called BS JTEM_CACHE, rep- 
resenting a cache of items found by analysis of buyers and sellers. Reading down the 
right column are data records representing sellers, an item cache, data records 
indicative of other bidders, and an archive of items of interest. 

[61] Turning to the "category'* database, it stores all the categories users of the site want 

items downloaded for. Its primary keys are Usemame and Category_id. 

[62] Usemame stores the usemame of the user storing this category. Category_id stores 

the auction system's unique identifier. The next few fields are: 

[63] Name: the text name of the category, according to the auction system it belongs to 

[64] Parent jaame: the text name of the category's immediate parent. NULL if said 
category is top-level. 

[6S] Sort.order: code that indicates how the items in the category should be sorted. 

4 

[66] 1 : ending date 

[67] 2: price ascending 

[68] 3: price descending 

[69] . 4: title 
[70] 5: # bids; 

[71] Filter .jninbids: minimum number of bids an item in this category must have in 
order to be displayed 

[72] Filterjrninprice: minimum price an item must have in this category in order to be 

displayed 

[73] Filter^maxprice: maximum price an item may have in this category in order to be 

displayed 

[74] . Filter_keywords: list of keywords the item must not include in order to be 
displayed 

[7S] Filter^egion: a region code the item must possess in order to be displayed in this 

category. 

[76] Highlight^words: a list of words that, if contained in the auction title, should be 

highlighted in some fashion. 
[77] Active: flag that tells the system whether or not to download items for this 

category. 
[78] 1: active 

[79] 0: inactive 

[80] Last^regen^date: date and time at which the system last fetched items for this 

category. 

[81] Last_,item_count: nxmiber of items downloaded from this category the last time the 

. category was processed. 
[82] Last_itemJ»tal: number of items the auction system claimed were in this category 

last time the category was processed. 
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83] Regioimame: the name of the region associated with the filter_jegion column, 

84] lAj'egen: data and time at which the current regeneration process was started. 

NULL indicates the category is not currently being processed. 
85] Pid: process ID number the system assigned to the script that is processing this 

category. NULL indicates it is not currently being processed. 
86] Turning to the "search" database (item 27 in Fig. 2), this stores all the search 

queries users want items downloaded for. Its primary key is "Searcluid." Fields 

include: 

87] Search_id: unique id number automatically assigned by the database each time a 

new search term is added. Uniquely identifies each stored search query. 
88] Query: the actual stored search query (text) to be sent to the auction system when 

searching for items. 
89] Usemame: usemame of the site user that is storing the query. 

90] Category_id: optionally, a user can specify a category to confine the search to. 

91] Category^name: the textual name of the aforementioned category. 

92] Parentjiame: the name of the parent category of the aforementioned categoryjd. 

NULL if category is top-level. 
93] Sort_order: code that indicates how the items resulting from the query should be: 

sorted. 
94] 1 : ending date 

95] 2: price ascending 

96] 3: price descending 

97] 4: title 

98] 5: # bids 

99] Filter jaiinbids: minimum number of bids an item resulting from; the query must 

have in order to be displayed 
100] Filter.minprice: minimum price an item resulting from the query must have in 

order to be displayed. 

101] Filter_maxprice: maximum price an item resulting from the query may have in 

order to be displayed. 
102] Filterjceywords: list of ke3rwords the item must not include in order to be 

displayed 

103] Filter.region: a region code the item must possess in order to be displayed in the 
query results. 

104] Highlight_words: a list of words that, if contained in the auction title, should be 

highlighted in some fashion. 
1 05] Active: flag that tells the system whether or not to download items for this stored 

search. 
106] 1: active 
107] 0: inactive 



« 
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108] Last_jegeiudate: date and time at which the system last fetched items for this 
search. 

1 09] Last_item_coiint: number of items downloaded from this search the last time the 
search was processed. 

110] Last_item_total: number of items the auction system claimed resulted from the 

stored search last time the stored search was processed. 
Ill] Lastjprefilter^total: number of items the stored search yielded before server-side 

filtering took place. 

1 12] Region jiame: the textual name of the region if the region filter was specified 
above. 

1 13] Injregen: date and time at which the current regeneration process started. NULL if 

search is not currently in regen. 
1 14] Search.desc: flag that indicates whether auction descriptions should be searched in 

addition to titles. 1 : search them. 0: don't, 
lis] Searcluoption: field to hold additional search options to be passed on to the 

auction provider. 

1 16] Pid: process ID number the system assigned to the script that is processing this 

search. NULL indicates it is not currently being processed. 
117] Turning now to the Bidder database - this is a table (item 28 in Fig. 2) that stores 

all of the other bidders being watched by users of the site. Its primary keys are the 

bidder Ebay_user_id and the Usemame. Fields include: 
118] £bay_userjd: unique user identifier that the bidder uses on the outside auction 

system. 

119] Usemame: unique user identifier of the user of this site. 

120] Source: flag that indicates whether the site user or the system added this bidder to 

the database. 
121] 1 : user added, 2: system added 
122] date.added: date this bidder was added to the database. 
123] Num^atches: the number of items the user of the site had in common with this 

bidder. IE: how many auctions did they both bid on. 
124] FiIter_words: list of words that, if present in the title of the auction, should be used 

to remove the item from the result set. 
125] Filter„minprice: minimum price an item must have in order to be part of the result 

set from this bidder. 

126] Filter_maxprice: maximum price an item may have in order to be part of the result 
set from this bidder. 

127] Last_regen^date: date and time of the last successfully completed regeneration 
process for this bidder. 

128] Injregen: date and time at which the current regeneration process started for this 
bidder. NULL indicates bidder is not being regenerated. 
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[129] Active: flag to indicate to the system whether or not items should be downloaded 
for this bidder. 

[130] Pid: process ID number the system assigned to the script that is processing this 

bidder. NULL indicates it is not currently being processed. 
[1 3 1] The next database is the Seller file, a table that stores all of the other sellers being 

watched by users of the site. Its fields include: 
[132] Ebay_user_id 
[133] Usemame 

[134] Ebay_userjd: unique user identifier that the seller uses on the outside auction 
system. 

[1 35] Usemame: unique user identifier of the user of this site. 

[136] Source: flag that indicates whether the site user or the system added this seller to 

the database. 
[137] 1 : user added, 2: system added 
[138] date^added: date this seller was added to the database. 
[139] Num^matches: the number of items the user of the site had in common with this 

seller. IE: how many auctions did they both bid on. 
[140] Filter_words: list of words that, if present in the title of the auction^ should be used 

to remove the item fi'om the result set. 
[141] Filter_jninprice: minimum price an item must have in order to be part of the result 

set firom this seller. 

[142] Filterjnaxprice: maximum price an item may have in order to be part of the result 
set firom this seller. 

[ 143] Items_with_bids: flag to indicate to the system whether or not items being 

downloaded must have at least one bid on them. 1 : only get items with bids, 0: doesn't 
matter. 

[144] Last_jegeiL.date: date and time of the last successfiiUy completed regeneration 
process for this seller. 

[145] In^regen: date and time at which the current regeneration process started for this 

' seller. NULL indicates seller is not being regenerated. 
[146] Active: flag to indicate to the system whether or not items should be downloaded 
for this seller. 

[147] Pid: process ID niunber the system assigned to the script that is processing this 

seller. NULL indicates it is not currently being processed. 
[148] A next database is the Usemame datbase, containing all the user account in- 

foimation for users of the site. Fields include: 
[149] Usemame: unique alphanumeric identifier users of the site use to log in. 
[150] Name„first: first name of the registered user. 
[151] Name_last: last name of the registered user. 
[1 52] Create_date: date the user account was created. 
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1 S3] Password: user's password, stored in hash format. 

1 54] Max^cat Jtems: maximum number of items to be downloaded for each category, 

by the system, for this user. 
1 55] Max_srchu.items: maximum number of items to be downloaded for each stored 

search query, by the system, for this user. 
1 56] Globaljiighlight: list of words that should be highlighted if encountered m an 

auction title. 

157] Auto_add_bidder: numerical constant specified by the user to tell the system when 

another bidder should be auto-added to the bidder watch list. 
1 58] Auto_add_seller: numerical constant specified by the user to tell the system when 

another seller should be auto-added to the seller watch list. 
159] Ebay_user_id: stores the unique identifier (usemame) this user uses on other 

auction sites. 

160] Injegen: stores the date and time at which the current regeneration process started, 
161] A next database is the Item Cache database. This is a table that stores information 

* 

about individual auctions that are downloaded as a result of the system browsing i 
categories or running search queries for the user of the site. The contents of this table 
. will change often - nothing is permanently stored. Fields include: 

1 62] Usemame: unique alphanumeric identifier users of the site use to log in. 

163] Categoryjd: unique identifier used by an outside auction system to identify a 
specific category. 

164] ' Searchu.id: relates to a stored search query in our database. ; 
165] Item_num: unique identifier used by an outside auction system to identify a 

specific auction item. 
166] Title: title of the item up for auction. 
167] Price: price of the item up for auction. 

168] Buyitnow: if the item has a ''buy it now" price,, it is stored in this column. 
1 69] Bids: number of bids currently on the item. 

170] Ends: string that describes when the auction ends - can either be a date or a 
number of days/hoiirs. 

171] Highlighted: flag indicating whether this item should appear as "highlighted" in the 

result set. 1: highlight, 0: not highlighted. 
172] Cuirency.type: indicates the type of currency the auction is using. 
173] A next database is the buyer-seller cache. This is a table that stores information 

about individual auctions that are downloaded as a result of viewing the buymg/selling 

habits of other auction system users. The contents of this table will change often - 

nothing is permanently stored. Fields include: 
174] Usemame: unique alphanumeric identifier users of the site use to log in. 
175] Item^num: unique identifier used by an outside auction system to identify a 

specific auction item. 
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[176] Source: flag that indicates whether the system entered this auction item or the user 

did. 1: iiser, 2: system. 
[ 1 77] Title: title of the item up for auction. 

[178] Start: a string representing the date at which the auction was initially listed. 
[179] End: string that describes when the auction ends - can either be a date or a mmiber 
of days/hours. 

[1 80] End_date: the 'end' column converted into a MySQL date type - for better sorting. 
[181] Bids: number of bids currently on the item. 
[ 1 82] Price: price of the item up for auction. 

[183] Seller^user^d: the unique identifier the seller of the auction uses on the external 
auction system. 

[184] Highlighted: flag indicating whether this item should appear as "highlighted" in the 

result set. 1 : highlight, 0: not highlighted. 
[185] Hbs: acronym for 'highlighted bidder or seller' - will store the unique identifier of 

the high bidder of the auction or the marked seller. 
[186] Type: flag that indicates whether this item belongs to a bidder or a seller on the 

external auction system. 1: seller, 2: bidder. 
[187] Currency_type: indicates the type of currency the auction is using. 
[188] Ebay.user Jid: the unique identifier the marked bidder or seller uses on the external 

auction system. 
[189] Uabs: multi-purpose flag column. 

[190] A next database is a database 29 of items of interest to the bidder 21. This is the 
item archive, a table that stores auction items that have been bid on, sold by, or 
specifically added by the user of the site. Items in this table are permanent and do not 
change very frequently. Fields include: 

[191] Usemame: unique alphanumeric identifier users of the site use to log in. 

[192] Item.num: unique identifier used by an outside auction system to identify a 
specific auction item. 

[193] Source: flag that indicates whether the system entered this auction item or the user 

did. 1 : user, 2: system. 
[1 94] Title: title of the item up for auction. 

[1 95] Start: a string representing the date at which the auction was initially listed. 
[196] End: string that describes when the auction ends t can either be a date or a number 

of days/hours. 
[ 1 97] Price: price of the item up for auction. 

[198] Seller_user_id: the unique identifier the seller of the auction uses on the external 
auction system. 

[199] Hbs: acronym for ^highlighted bidder or seller' - will store the unique identifier of 

the high bidder of the auction or the marked seller. 
[200] Currency„type: indicates the type of currency the auction is using. 
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201] Date.added: date and time at which this item was entered into the system. 
202] Status: indicates the status of the auction: 
203] 0: auction still in progress 
204] 1 : auction ended 

205] A next database is the call tracking database, which is a table to log each time a • 
call is made to eBay (page download) and what type of call it was. Fields include: 

206] Usemame: usemame of the system that was logged in and is responsible for the 
call being made. 

207] Call_id: nimiber that identifies what type of call was niade: 
208] 1 : category browse page 
209] 2: search results page 
210] 3 : bidder items page 
211] 4: seller items page 

212] date.time; the date and time at which the call was made to the external auction 
system. 

213] Another database is the "other bidders" table, which keeps a running tally of which 
extemal auction users have bid on which items in the item_archive. Fields include: . 

2 14] Usemame: unique alphanumeric identifier users of the site use to log in. 

2 1 5] Item^um: unique identifier used by an outside auction system to identify a 
specific auction item. 

2 1 6] Other_ebay„user_id: the unique identifier the marked bidder or seller uses on the 

external auction system. 
217] Finally there is an error log table, which stores system-generated and handled error 

exceptions. Fields include: 
218] Error Jd 

219] Error_id: auto_incremented number assigned by the database every time a new 
error is logged. 

220] Date_time: date and time at which the error was logged. 

22 1 ] Usemame: usemame that was responsible for the handled error. 

222] Error^msg: message detailing the error and how it was caused. 

223] Fig. 6 shows a user interface flowchart for apparatus according to the invention. At 



left is a user login page. This leads to a main page firom which the user can jump to any 
of several sub-pages. Buttons on the main page include "View Items From Other 
Bidders" which leads to a page which shows all items from bidders on the 'bidder 
watch list' in a sorted table. The next main-page button is "View Items From Other 
Sellers" which leads to a page which shows all items from sellers on the 'seller watch 
list' in a sorted table. The next main-page button is "View Search Results" which leads 
to a page which shows all items downloaded from the stored searches in a sorted table. 
The next main-page button is "Browse Categories" which leads to a page which shows 
all items downloaded from the categories in a sorted table. (Note that the term 
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'"categories" as used here corresponds to the '"classifications" discussed above.) 

[224] Next on the main page is a "management" area. The first button here is 

"Bidder/Seller Manager" which permits the user to add, edit, or remove external 
auction users &om the user's bidder/seller watch lists. Next is a ''Search Manager" 
button which permits the user to manage stored search queries that will retrieve 
auction items. Next is a "Category Manager*' button which peimits the user to manage 
categories that will retrieve auction items. 

[225] Another button on the main page is "Manage My Items Archive." This permits the 
user to view and manage the auction item archive kept by the system. User may also 
manually add auctions of interest here, though typically items sold by or bid on by the 
invention user are kept here. 

[226] Yet another part of the user interface is a button permitting the user to configure 
the number of matches that will trigger adding a competing bidder to one's hst of 
competing bidders, or for adding a seller to a premier seller list. 

[227] It is helpful to describe an exemplary language platform, namely a computer server 
running web server software, such as the Apache web server. In this exemplary 
embodiment, the scripting language used for implementation of this service is PHP. 

[228] PHP is a widely*used general-purpose scripting language that is especially suited 
> for Web development and can be embedded into HTML. The language also has a vast 
array of fimctions available that are tailored to downloading information in an eflBcient 
maimer firom the Internet. The apparatus according to the invention uses PHP not only 
to display information to the user dynamically through the web interface, but also as 
the scripting language of choice for gathering data firom external auction sources on 
the Intemet. 

[229] PHP is extremely fast and well-integrated to the Apache web server software. This 
makes for fast and efiicient processing of data both inside and outside the current 
invention system. 

[230] The relational database management system (RDBMS) used in the preferred 
embodiment of the current invention is MySQL (www.mysql.com). MySQL is a 
continually-evolving open-source software creation, meaning it benefits from the input 
of many contributors around the world. MySQL is particularly good at interfacing with 
the PHP scripting language for the purposes of storing and retrieving small or large 
amounts of data with relatively good speed and scalabiUty. 

[23 1] A basic example of these two technologies, PHP and MySQL, being used together 
for the purposes of the current invention, is the process of storing values such as how 
many items are listed on a particular external auction service that match a particular 
search query. 

[232] The following code shows how data can be saved to the MySQL database, from 
within a PHP script, with only 2 lines of code, or 3 if you count the fimctionless 
comment line. 



I 
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[233] #tell database how many prefiltered items there were 

[234] $sql = "UPDATE 'category^ SET ^lasCprefilter^totar = $prefilter.total WHERE 
'usemame' = *$usemame* AND 'category Jd' = $categoryJd"; 

[235] Sresult = mysqLquery($sql,$db) or die("UPDATE SQL Failed: $sql\n"); 

[236] It is instructive to discuss some of the imier workings of an ASP embodiment of 
the apparatus according to the invention. The apparatus requests, receives, parses, and 
consequently stores auction data related to a category on the eBay auction system. 
What follows is one example of the many different types of auction data that can be 
downloaded. Using the PHP programming language, a function called 
'browseCategory' is defined for the purpose of downloading and parsing auction data 
based on a category ID number passed into the function. 

[237] First, the filters are retrieved from the MySQL database that are associated with 

this category for the particular user that is currently logged in. The usemame logged in 
is globally known because it is part of the session's data. 

[238] #look up filters for this category 

[239] $sql = "SELECT 

•'sort_order\'filter_niinbids\'filterjtninprice\'filter_maxprice\'filter_^ 
.■r_region' ,'highlight__words' 

[240] $sql = $sql . " FROM 'category' WHERE ' category Jd' = $categoryJd AND ■ 
'usemame' = '$usemame'"; 

[241] • Sresult = mysqLquery($sql,$db); 

[242] Smyrow = mysql_fetch_array($result); 

[243] $sort_order = $myrow["sort_order"]; 

[244] $filter_minbids = $myrow["filter_minbids"]; 

[245] $filter_minprice = $myrow["filter_minprice"]; 

[246] $filter_maxprice = $myrow["filter„maxprice"]; 

[247] Sfilterjceywords = $myrow["filter_keywords"]; 

[248] $filterj:egion = $myrow[ "filter jegion"]; 

[249] $highlight__words = $myrow["highlight„words"]; 

[250] if ($fdter„minprice = "0.00") { 

[251] Sfilter^minprice = ""; 

[252] } 

[253] if (Sfilter^maxprice = "0.00") { 
[254] $filter„maxprice = ""; 
[255] } 

[256] Once the filters have been retrieved and stored in local variables, a URL must be 

generated to send as a page request to eBay. 
[257] This is done by embedding the category number into a pre-defined eBay URL 

template: 
[258] #prepare url 
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[259] $url « Vaw/plistings/Iist/all/category' . Scategoryjd . Vindex-htmr; 
[260] $url = $url . "?region-$filterj-egion"; 

[261] Now, a loop is initiated which will generate all the necessary URLs to be sent to 
eBay. 

[262] while ($next_link != and $pages_done < $max^pages) { 
[263] Snextjink = *http://listings.ebay.com' . $next_link; 

[264] Inside this loop, each page is fetched via an HTTP call and broken down into its 

separate tables by a function called page2tables. 
[265] #break page down into all its tables 

[266] $tmp_tables = page2tables($nextjink, Sindicator, 1 , $&st jpage, Ssavedjine j)tr); 

[267] Page2tables is passed a string called an 'indicator', which tells the function what 
text to look for that should indicate that a group of 5-celled item tables are coming 
soon. In the current case of browsing category results, the string "items found'' 
indicates that the very next table encountered in the HTML will be an item table, so we 
will capture its data! 

[268] #this indicator lets us know that the next table after this one will be an item table 
[269] Sindicator = "items found"; 

[270] After all of the links have been generated, sent to eBay, and downloaded, the 
specific auction data needs to be parsed out, cleaned up, and stored in the database. 

[271] A function called tables2items does this and stores the results in an item_array, ^ 
which is a multi-dimensional associative array used to stored multiple auction listings 
and all of the data associated with each auction in an organized fashion. 

[272] #tum tables into ebay items 

[273] Sitemjrray = tables2items($tables); 

[274] Quoted below is exemplary code used to parse the tables £rom eBay pages into 

clean auction data. This section of code happens to be specific to the eBay service and 
will only work on that service. The routine only processes a table from eBay if the 
table had 5 cells, a characteristic unique to item-holding tables. It uses regular 
expression functions to split apart strings and parse out the valuable data. 

[275] ^extract search results from the tables 

[276] foreach (Stables as Stable) { 

[277] Sthis jLum^cells = sizeof($table); 

[278] #only read this table if it has 3 cells (like an item) 

[279] if($this^unucells==5){ 

[280] $celLnum = 0; 

[28 1] foreach (Stable as Scell) { 

[282] switch (ScelLnum) { 

[283] caseO: 

[284] #item_jium 

[285] Scell = strip_tags($cell); 
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286] 


#item nximber may not be in this cell all the time 


287] 


if($cell = ""){ 


288] 


$get Jtem_;ium = 1 ; 


289] 


} 


290] 


else { 


.291] 


$itenuarray['item_p.um'][$iten\_cnt] = $cell; « 


292] 


} 


,293] 


$ceHjMmi++; 


294] 


break; 


295] 


easel: 


;296] 


#get item number from hief tag if need be 


297] 


if ($get item num = 1) { 


:298] 


$data = split("item=",$cell); 


:299] 


$clata2 = splitC">',$data[l]); 


300] 


Sitem^num = $data2[0]; 


301] 


#1 1-22-2002 - &category is showing up in item num, strip it out 


302] 


$data = split("&",$itemjtum); 


303] 


$item_num = $data[0]; 


304] 


It u 

mt 


305] 


$item_aiTay['item^nxmi'][$itenucnt] = $item^um; 


:306] 


' $get_item_num = 0; 


307] 


} 


308] 


#title and icons (ignoring icons currently) 


:309] 


$cell = strip_tags($cell); 


:3io] 


$cell = strjeplaceC"",""",$celi); 


■311] 


$item_array['title^[$item_cnt] = $cell; . 


312] 


$celljium++; 


313] 


break: 


[314] 


case 2: 


315] 


#price 


[316] 


$cell = strip_tags($cell); 


[317] 


$data = ""; 


[3181 


JRcurrencv tvne = 


[319] 


#7-24-2002 ebay included the buy-it-now price in the same field 


[320] 


#look like: $30.00$40.00 or GBP 12.00 or GBP 4.00GBP 12.00 


[321] 


if (stristr($cell,'$') and !stristr($celi;C') and !stristr($cell,'AU')) { 


[322] 


#split on $ if it has a $ (not Canadian or AU) 


[323] 


$data = preg_splitCA$/*,$cell); 


[324] 


} 


[325] 


elseif (stristr($cell,'$') and stristr($cell,'C')) { 
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[326] 


#canadian money 


[327] 


$cuirency_type = "C"; 


[328] 


$data = splitC'C ",$cell); 


[329] 


$data[l] = strj-eplace('$V',$data[l]); 


[330] 


$data[2] = strjreplace('$',",$data[2]); 


[331] 


} 


[332] 


elseif (stristr($ceU,'$') and stristr($cell,'AU')) { 


[333] 


#australian money 


[334] 


#AU $2.00AU $4.95 


[335] 


$cuirency_type = "AU"; 


[336] 


$data = splitC'AU ",$cell); 


[337] 


$data[l] = str_replace('$',",$data[l]); 


[338] 


$data[2] ?= strj-eplace('$',",$data[2]); 


[339] 


} elseif (stristr($ceU,'GBP')) { 


[340] 


#british money 


[341] 


$currency_type = "GBP"; 


[342] 


#GBP4.00GBP 12.00 


[343] 


#must split on GBP 


[344] 


$data = preg_split(VGBP /',$cell); 


[345] 


} elseif (stristrCScell/EUR*)) { 


[346] 


#eiiro money 


[347] 


$cuirency_type = "EUR"; 


[348] 


#GBP4.00GBP 12.00 


[349] 


#must split on GBP 


[350] 


$data = pre&_split('/EUR /',$cell); 


[351] 


} 


[352] 


$item_airay ['price*] [$itein_cnt] = str_replace(V,",$data[l]); 


[353] 


$itein_array['buyitnow*][$item_cnt] = strjreplace(',V'>$data[2]); 


[354] 


$item_array[*ciirrency_type'][$itenucnt] = $ciirrency„type; 


[355] 


$celljaum++; 


[356] 


break; 


[357] 


case 3: 


[358] 


#bids 


[359] 


$cell = strip_tags($cell); 


[360] 


$item_array ['bids'] [$item_cnt] = $cell; 


[361] 


ScelLnum-H-; 


[362] 


break; 


[363] 


case 4: 


[364] 


#ends 


[365] 


$cell = strip_tags($cell); 
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[366] $item_aiTay['ends'][$itenucnt] = Scell; 

[367] $cell^um+H-; 

[368] break; 

[369] } 

[370] } 

[371] $item_cnt-H-; 

[372] , } 

[373] } 

[374] } 

[375] After the item_array of eBay auction items is returned to the browseCategory 
function, the filters predefined for this particular category by this particular user are 
applied. The same regular expression and string comparison tactics are used in this 
process as well. Once a final array of items is created that has passed the filters and . 
that has been appropriately highUghted, based on the predefined 'highlight words', it is 
returned to the calling script, in this case, the regeneration script for categories. 

[376] The regeneration script itself then loops through the array of eBay items and inserts 
the data into the MySQL database. 

[377] If, at any point in this process, an error occurs, such as a page from eBay is 

downloaded and found to be incomplete, or code is not where it was expected to be, an 
error message is genemted and logged. 

[378] The error message will mdicate what line of code the exception occurred, what the 
session variables were at the time of the error, and what some of the circumstances 
were, regarding eBay, at the time of the error. All of this information is invaluable 
when tracking down a bug or when compensating for changes on eBay's end of the 
operation. 

[379] Having discussed some of the system design issues, it is instructive to discuss how 
threads are spawned to handle the many tasks required to serve the user well. This 
involves an accoimt of the allocation of tasks to foregroimd and background. 

[380] The following '"pseudo code" describes how scripts for regenerating databases are 
brokered, queued, and launched in order to download items from the external auction 
service for the users of this invention. 

[381] . It should be noted that the term "regeneration" or "regen" refers to the process of 
the invention making HTTP requests to the external auction service, receiving raw 
HTML back, parsing the HTML, applying filters and highlights, and saving the 
auction data in the local database. This process can be scheduled to run at any given 
interval or can be done upon user login. 

[382] Main Page Tasks: 

[383] Fetch total number of system threads allocated to the application (stored in a config 
file) ( max_threads. 

[384] Determine how many threads this particular user may use to regenerate auction 
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data. 

max_threads_for.user = max_threads / nuiiijisers„online 
[385] Script launching routine: 

[386] Bidders: # of threads to spawn for regeneration of bidder data = the number of 

bidders that need to be refreshed / a numerical constant (ie: 4) 

update the value of threads Jejft (threads available for the spawning of other processes) 

( threads Jeft = threadsjeft - bidders Jaunched 
[387] Sellers: # of threads to spawn for regeneration of seller data = the number of sellers 

that need to be refreshed / a numerical constant (ie: 4) 

update the value of threads_left (threads available for the spawning of other processes) 
( threadsjeft = threadsjeft - sellers Jaunched 

[388] Searches: launch as many seller regen scripts as needed or as possible, provided the 
"threadsjeft" value is not 0. 

[389] Categories: launch as many category regen scripts as needed or as possible, 
provided the *threadsjeft" value is not 0. 

[390] This process, carried out by the main page upon initial log in of the system user, 
gives specific priority first to the bidders and then to sellers, because they normally 
complete quickly. After those two groups are done, the more time-consuming searches 
and categories may consume system resources. This is done to maximize system . 
efficiency and give the user something to look at (bidder and seller items) while the 
more resource-intensive tasks are being carried out. 

[391] Once these regeneration scripts are launched from the main page upon initial log- 
in, the user may stray from the main page and not worry about the tasks that need to be • 
completed. The scripts will call each other upon completing, in order to keep making 
progress, as described in the pseudo code below. When displayed, however, the main 
page will refresh regularly to let the user know how the process of regeneration is 
coming along. For instance, the main page may say something to the effect of: 

[392] "Currently Fetching Data for 10 Categories. 15 are waiting in Queue and 25 are 
ready for viewing." 

[393] Background Script Processing: 

[394] Regeneration Script Tasks: 

[395] There are four different types of regeneration scripts — one for bidders, one for 
sellers, one for searches, and one for categories. They all take the basic form of the 
logic outlined in the following pseudo code. Their main differences are the sections of 
the extemal auction site in which they query, and how/where they store the data that 
comes back from the external sources. 

[396] <regen start> 

[397] thisjpid = obtain system PID number this process is currently using. 
[398] While the life time of the script is less than predefined constant (ie: 15 minutes), do 
the following tasks: 
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[399] obtain an external auction site usemame from the database that still needs to be re- 
generated. 

[400] if one does not exist, continue to final routine of the script 
[401] , otherwise, do the following steps: 

[402] let the database know that this instance of the regen script is claiming re- 
sponsibility for the external auction site usemame obtained from the database, using 
the aforementioned PID (thisj)id). 

[403] Check to see if thisj)id is the PID on record in the database for this external 
auction site user„id. 

[404] If so, we have successfrilly locked &e row, so continue to download items for this 
user or category. 

[405] Otherwise, go back to step one and fetch another name to try the process again. 

[406] Once looping is finished and aU the items for this particular bidder/ 

seller/category/search have been downloaded, check to see if there are other bidders/ 
sellers/searches/categories to be regenerated by using the exact same logic outlined in 
steps 1-3 of Main Page Logic (above). 

[407] After doing the check and spawning a new process (if needed), terminate 
, graceftilly. 

[408] Those skilled in the relevant art will have no difficulty whatsoever devising myriad 
obvious variants and improvements to the invention, all of which are intended to be 
embraced withm the claims which follow. 



